跨国互联网公司并购，如何实现统一的IT管理？

“

互联网企业的并购不仅是组织结构的融合，更是产品架构和产品团队的融合。

特别是涉及不同的企业文化、技术能力甚至是不同的国家法律法规上的融合，存在更多看不到的隐形成本。

近日，由 51CTO 主办的第十六期以“Tech Neo”为主题的技术沙龙在北京举行，此次活动邀请了来自 Thought Works 高级咨询师顾宇老师。

他分享了一个东南亚互联网企业并购中的 DevOps 促进并购的实施案例，即通过在 AWS 上使用 Ansible 和 Cloud Formation 作为基础设施即代码的工具实现产品架构的迁移。

本文介绍如何通过 DevOps 的基础设施即代码实践，把架构以及开发/运维实践和规则固化为配置和代码。

让所有的团队和成员能够依照同样的规则进行开发和运维；通过自动化的手段加速团队、产品和架构的融合过程，提升整个组织的技术水平。减少组织间的沟通摩擦。

跨国互联网公司并购案例

案例梗概

某企业收购了分布在泰国、马来西亚、印度尼西亚、新家坡等地的几家东南亚拥有相同业务的互联网公司。

但如何在多国家、多语言文化的情况下，进行分布式 IT 敏捷产品团队的合并、步调一致的工作和实现统一的管理成为难题。

剖析组织现状

既要保留各个国家的业务团队，又要集中管理 IT 团队，首当其冲的是剖析组织现状。那么，做架构迁移要先了解哪些组织现状呢？

康威定律原话：Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations。

这句话中“constrained”的意思是强制。也就是说，当系统架构与组织架构不匹配时，系统结构会被强制转化成与组织架构一致。

要做到组织架构和基础设施架构保持一致，就需要根据未来的组织结构设计系统架构，减少系统架构演进中的适应性浪费。

如下图，是合并前架构的情况：

如图中所示，每个国家的公司运营着自己的网站。其中每一公司都有一部分是用 WordPress 运营的。

虽然都是 WordPress，但应用架构和使用方式上存在着诸多的差异。我们首先是要识别出这种差异。而这种差异不仅仅是技术上的，还有组织上的。

并购并不仅仅是把团队合并到一起就能解决问题，而是要把多国、多语言、多站点，变成多国、多语言、单站点。

通过一个站点来支撑多个地区的业务，这里选择马来西亚作为这个站点进行举例。

那么，组织架构就会办成如下图所示：

当组织架构变成多国、多语言、单站点，那么所对应的就是一个 IT 团队。如图可以看到把 Dev、Ops 分开来表示，这样的组织结构和 DevOps 有什么关系呢？

这就需要了解下 DevOps 的两种组织形式：

• Team OwnOps：团队内自有的 Ops，把 Ops 当做团队成员，实现开发和运维合作。

• Team ShareOps：不同产品开发团队之间共享一个 Ops。在这种情况下  Ops 团队就是一个平台团队。

为新组织设立目标

做团队合并之前，要为新组织设立目标，如下：

• 单一的产品开发团队及运维团队，各地区共享，由统一的产品经理协调各地的开发任务和业务需求。

• 每个地区可自有开发团队，但都由马来西亚开发团队来统一管理，所有运维都由马来西亚团队来支持。

• 在所有公司构建 DevOps 文化及机制，从 Team Own Ops 向 Team Share Ops 变化。

• 提升各个国家的 Dev / Ops 水平，当水平达到一致，便可通过 DevOps 这个中间桥梁打通。

用 DevOps 加速团队之间合并的进程

虽然 IT 团队来自不同的国家，分布在不同的地理位置，他们的文化背景不同，说着不同的英语方言，但是大家的技术栈是相同的。

一方面，我们通过 Zoom 构建起了每天的在线视频会议，及时同步各个团队之间的状况；另一方面，我们遵守着同样的开发规则。

其中，测试驱动开发（TDD）在这样的分布式团队中十分重要。虽然对编程语言和技术框架的理解不同，但是自动化测试为开发人员构建出了统一的理解。

这样就使得每个团队，每个成员去设计、实现自动化测试。一方面，用测试作为对需求的理解，减少和降低了不一致性；此外，通过测试驱动开发可以保证代码品质，进而提升程序员的编码水平。

自动化测试在这里就相当于一种代码质量的标准，组织被合并之后，架构也要随之改变，这时就要着手做架构迁移。可以用基础设施即代码把自动化作为一种制度去提升整体运行效果。

系统架构的迁移实践

系统架构迁移要在了解当前组织架构现状的前提下，制定架构的目标、设计迁移策略。这三方面落实后，才能为新组织设计新架构。

架构要尽量设计为设定的最高要求，这里不要将就现有人员的能力/精力，但是要规划成本，成本规划里不光要考虑迁移成本，还要考虑迁移后的维护成本。

这样，有了最高的要求和标准，可以引导大家为共同的结论和方向一起努力，既可以提升个人及团队的技术能力，也是提升 DevOps 合作的过程，因为好的架构一定是和多方利益相关者在不断沟通下形成的。

通过不断的开发团队沟通，解决开发痛点，来主动提升 Ops 团队的合作意识。

所以，DevOps 不仅是自动化，更是在磨合和共识团队合作的价值观和工作方式。

当前的组织与系统架构存在的问题

当组织和产品进行合并之后，不同的地区多系统的运维就变成了单一系统的运维。

因此，很多运维人员不再被需要，在现在的案例中，仅剩四名运维工程师，剩下的运维工程师相继离职，运维工作由技术负责人兼任。

这里遇到的问题是，如此少量的运维人员，如何维护大量技术栈/语言/业务各异的站点。

因为产品简单了，但架构复杂了，运维的环节和结点更多了。此外，为了避免账户单点，平均每个系统至少要有三个 AWS 账户：开发环境、测试环境及生产环境。

这样一来，三个人维护二十多个账户是一种浪费，还需要做账户合并。

这三个运维人员还需要应对风格各异的其他遗留系统，因为每一个国家的系统都分别由不同的架构师主导，对于仅三人的运维团队来说也是非常大的挑战。

尽管收购的企业核心业务相似，但每个国家的现状、市场条件、用户群都不一样，所以仍然需要一部分本地定制化业务。

总之，在系统架构方面存在的主要问题如下：

• 每个国家的架构都由不同架构师设计，所以会留下很多隐藏知识，以至于维护困难。

• 基础设施即代码已在一些 IT 团队中被使用，却没有用好，存在很多硬编码。

• 旧架构在更新一个应用时，就需要把整个架构全部更新，并非部分更新。

架构迁移的目标

综合当前新组织的现状与旧架构的问题，制定架构迁移目标如下：

• 实现用基础设施即代码管理所有的基础设施，因为旧架构还有些应用在机房裸机上运行，并且需要手动安装。

• 现有基础设施架构全部迁移到云上。

• 基础设施的管理要规范化，可以把基础设施即代码看成一套制度，用来规范运维人员如何操作基础设施。

• 给所有运维人员、开发工程师提供统一界面，让他们基于基础设施即代码之上进行应用开发，进而实现部分更新，而不是全部更新。

• 实现能力和组织结构的迁移，基础设施即代码首先作为一个制度可保证以上几点。基础设施即代码一旦作为制度，在执行的过程中，要做到的最后一点就是能力的提升，即把基础设施变成一种产品。

如何把基础设施变成一种产品？步骤如下：

• 把基础设施架构经验在不同团队中复用，让不同国家、程序员、运维人员获得更安全，更稳定，更灵活的架构。

• 实现高度自动化，可以快速建设和定制。

• 要做到关注点分离，根据场景把变更缩小在一定的范围里。

• 要把开发和各环境做到抽象一致性，便于不同团队能够在不同环境中做到无缝切换。

架构的迁移策略

架构迁移有两大原则：

• 最少的变更，实现做到只做一个简单的变更，就完成迁移。

• 最小的影响，就是减少架构变更造成的不良影响。

架构迁移的整个策略如下：

• 将遗留系统应用按照（架构/应用/数据）进行封装。

• 用基础设施即代码构建一套新的架构，构建可复用架构模型。

• 对架构/应用/数据这三部分别用该脚本实施自动化迁移。

• 测试完成后切换总域名，切换子域名。

• 两周过后，遗留系统下线。

此架构策略除需要手动切换域名之外，其余全部实现自动化。

主要涉及技术如下：

• 用 Ansible + Cloudformation 封装并构造新的基础设施。基础设施要能做到随时可以完全恢复。

• 全量数据 dump / import，自动化备份到 s3 上，减少数据库的状态。

• 用 Docker 封装 wordpress 应用。不同的国家用不同的主题和插件组合完成。

• 用 cdn + nginx + wordpress 共同做 301、302 跳转，要为每个角色做好区分。

• 用脚本做迁移，迁移脚本分类（开发/测试/生产）管理。

• 切换域名指向（手动）。

为新的组织结构设计架构

对组织进行重建，确定新组织对应架构的目标和策略之后，紧接着就是根据使用场景，设计基础设施即代码的架构，实现整个架构自动的搭建和还原。然后，根据使用场景设计安全策略，避免人为操作，减少人为故障。

顾宇老师认为，基础设施即代码和基础设施是类和对象的关系。通过定制化的模板结合不同的场景产生不同的基础设施实例。

一方面统一了架构语言；另一方面减少了不经审计的认为操作。此外，可以采用面向对象原则进行逻辑分层，隔离不同场景的关注点。

例如：持续交付关注 Docker 镜像的部署和变更，应用维护关注日志的查询和操作。

写在最后

在该案例中，利用基础设施即代码技术有几个关键要点，总结如下：

• 架构迁移要为组织结构迁移服务。

• 把自动化和基础设施即代码当做制度使用（康威定理和逆定理）。

• 把基础设施即代码当做一个产品开发。

• 安全的架构和架构的安全。

• 基础设施逻辑分层。

• 基础设施即代码本质上是一套类库，从面向对象的原则考虑基础设施的设计。

• 构建每日可用架构。

由于篇幅原因，还有众多相关细节没有一一纳入文章中，想要了解更过内容的开发者，可点击“阅读原文”查看视频与“回复关键词”下载PPT。

微信后台回复关键词“并购”，即可下载完整版PPT资料

作者：王雪燕

编辑：陶家龙、孙淑娟

投稿：有投稿、寻求报道意向技术人请联络 [e-mail]

顾宇，ThoughtWorks 高级咨询师。专注于 DevOps、持续交付，微服务以及全功能产品团队的设计、实践、落地以及经验推广。并持续在多个专业平台和媒体发表相关文章，受多个行业大会邀请发表相关演讲。在加入 ThoughtWorks 之前，曾经参与中国移动 10086 呼叫中心以及中国联通省级 BOSS 系统的研发、实施和割接。任项目经理，维护经理，开发工程师等职务，拥有丰富的大型 IT 系统小型机生产环境实战经验。

精彩文章推荐：